chore: update rhiza to v1.4.2 - #936

What

Migrates this repo from rhiza v1.3.4 to v1.4.2.

v1.4.0 stopped shipping the make layer, so this is not an ordinary /rhiza:update. The
sync deleted Makefile, .rhiza/rhiza.mk, all eleven .rhiza/make.d/*.mk fragments and
.rhiza/.env — and the settings those files carried are not the rhiza-task CLI's
defaults. Recovering them is the substance of this PR; the version bump is the easy part.

Sync result: 8 files merged, 15 deleted, no conflicts (nothing to take from upstream),
no .rej files. All 15 deletions were verified template-owned at the old ref, so no
repo-owned file was lost to the delete pass. docs/paper/README.md is new from the
github-paper template.

Settings recovered into [tool.rhiza-task]

DEPTRY_FOLDERS += api — the one with no direct equivalent

v1.4.0 removed the DEPTRY_FOLDERS accumulator and now derives the deptry folder set
(source_folder plus marimo_folder), with no setting to extend it. Reproduced locally:
without api/ in scope, deptry reports DEP002 'fastapi' defined as a dependency but not used in the codebase, so the deps gate fails.

The deps task appends deptry_ignore to deptry's argv after the derived folders, and
deptry takes multiple roots positionally — so a bare path there restores the previous scope
exactly. Verified through the real CLI: uvx rhiza-task@0.3.1 deps → ok deps, 70 files
scanned, matching the pre-migration scope.

Suppressing the finding with a per_rule_ignores entry would have been the weaker fix: it
would also stop flagging fastapi if api/ ever genuinely stopped importing it. The stale
comment in [tool.deptry.per_rule_ignores] that pointed at the deleted DEPTRY_FOLDERS
line has been repointed.

Not migrated, on purpose

Matching the CLI default already: source_folder, tests_folder, uv_sync_args,
license_fail_on, book_output, zensical_version, paper_folder. Also left unset, each
with the reason recorded in pyproject.toml:

• mkdocs_extra_packages — the old Makefile set --with 'mkdocstrings[python]', now the
  default. Naming the setting replaces the default list, so restating it invites someone
  to append a package and silently drop mkdocstrings.
• license_ignore_packages — marimo.mk appended docutils; rhiza-task adds it itself
  when the marimo tasks are registered.
• ci_os_matrix — .rhiza/.env documented leaving this unset so rhiza_ci.yml picks the
  matrix per caller. Pinning it here would defeat that.
• layers / rhiza_checks — both derived. layers comes from the manifests present
  (pyproject.toml → python), and the check set follows from it, still yielding all
  five checks the make accumulators built up (the RHIZA_CHECKS += lines in python.mk,
  quality.mk and test.mk are fully covered by NEUTRAL_RHIZA_CHECKS + the python
  layer).

PROJECT_NAME_EXTRA and LOG_LEVEL from custom-env.mk were cosmetic and have no CLI
equivalent.

Two gates that needed more than a setting

1. The architectural import contracts. The old Makefile ran import-linter from an
arch target hooked in with test:: arch, which made it a CI gate only because v1.3.x
CI ran make test. v1.4.2's rhiza_ci.yml runs uvx "$RHIZA_TASK" test directly, so a
Makefile hook no longer reaches CI at all — the [tool.importlinter] contracts would have
gone unchecked while every job stayed green.

Moved to a repo: local pre-commit hook, which runs under rhiza-task fmt — what the
ci / Pre-commit hooks job executes. It uses uv run --with import-linter lint-imports,
the same command the arch target used: an isolated language: python hook fails with
Could not find package 'jquantstats' in your Python path, because import-linter resolves
root_package by importing it and needs the project itself available.

Verified it can actually fail, not just pass: injecting a forbidden
from jquantstats.data import Data into _stats/_basic.py gives
Contracts: 1 kept, 1 broken, and it returns to green once reverted.

2. Two task names shadowed by paths in this repo. The shim routes unknown targets
through a %: match-anything rule, which make only applies when it cannot resolve the
target as a file. This repo has a book/ directory and a license file at the root, and
both book and license are task names — so make book and make license resolved to
the path and printed "is up to date" without running the gate.

Note .PHONY alone is not the fix, and it fails in the direction that looks fine: make
never applies a match-anything rule to a phony target, so declaring them phony and stopping
there yields Nothing to be done for 'book' — still a silent pass. They get an explicit
forwarding rule as well, with .PHONY on top. docs/ needs no guard: the task is
docs-coverage and nothing is called docs.

The restored Makefile is otherwise the stock uvx rhiza-task shim. MKDOCS_EXTRA_PACKAGES
and DEPTRY_FOLDERS from the old one are handled above and are not carried into it.

Exclude list

Left unchanged. All three entries (rhiza_fuzzing.yml, rhiza_weekly.yml,
rhiza_scorecard.yml) are already in working destination form rather than the dead
clone-relative bundles/github/... spelling, and v1.4.2 still ships all three, so each is
live and doing its job. The exclude sweep found all three paths absent — nothing left
behind by an earlier sync, tracked or untracked. Nothing was added: the house set would
have excluded and deleted rhiza_mutation.yml, .github/CONFIG.md, .github/ISSUE_TEMPLATE
and .github/DISCUSSION_TEMPLATE, all of which are tracked and present here — an editorial
call, not part of a version bump. The chore: delete the newly excluded template files
commit is therefore absent, as there was nothing to delete.

Worth a look, not fixed here

• FUZZING_ENABLED=true is set as a repository variable, but rhiza_fuzzing.yml is
  excluded and absent — so nothing fuzzes. Pre-existing, unrelated to this bump, and the
  fix is a decision either way (drop the variable, or drop the exclusion and let the sync
  deliver the caller).
• CLAUDE.md is now stale and is repo-owned documentation, so it belongs in its own PR:
  it cites COVERAGE_FAIL_UNDER = 100 in .rhiza/make.d/custom-env.mk (that file is gone —
  the value now lives in [tool.rhiza-task]), describes the Makefile as including
  .rhiza/rhiza.mk, still says template v1.2.0, and lists a make deptry target whose
  actual name is deps.
• RHIZA_TASK in the shim is rhiza-task@0.3.1, matching the pin rhiza_ci.yml@v1.4.2
  uses for every gate step — so local make and CI run the same code. No divergence to
  report.
• The shim's uv bootstrap block is retained. v1.4.2's pre-commit job does now have its own
  setup-uv step, so the block is arguably dead weight, but it only fires when uvx is
  absent and removing it is a repo-owned change for its own PR.

Gates

No gates were run — /rhiza:quality produces the scorecard. The exceptions are the two
checks used as evidence above: uvx rhiza-task deps (to prove the api/ scope regression
and its fix) and uvx prek run import-linter --all-files (to prove the arch gate both
passes and can fail). make fmt was deliberately not run, as it would rewrite repo-owned
files.

CI caught one more regression

The first push went red on all four Python versions, plus book / build and
Lowest-direct dependency compatibility — 13 failing checks, all one root cause:

FAILED tests/test_jquantstats/test_coverage_gate.py::test_coverage_gate_is_100
  CalledProcessError: Command '['/usr/bin/make', '-s', 'print-COVERAGE_FAIL_UNDER']'
  returned non-zero exit status 2

tests/test_jquantstats/test_coverage_gate.py existed to guard exactly the setting this
PR migrates — it read the value back through make -s print-COVERAGE_FAIL_UNDER, and the
make layer's print-% target went with v1.4.0. book / build failed as
blocked: prerequisite failed: test, and the lowest-direct job runs the same suite, which
accounts for all 13.

Worth noting what the log showed around the failure: --cov-fail-under=100 was on the
pytest command line and Required test coverage of 100% reached — so the recovered
coverage_fail_under was already working. Only the test's probe was stale.

Rewritten to read [tool.rhiza-task] coverage_fail_under straight from the committed TOML
via tomllib — no subprocess, no uvx, no network. It also now asserts
[tool.coverage.report] fail_under alongside it, because the two are independent: the
command-line --cov-fail-under outranks the config file, so a bare pytest run and a
rhiza-task test run would enforce different numbers if they ever drifted apart.

Verified the guard still bites: commenting the setting out gives
AssertionError: [tool.rhiza-task] has no coverage_fail_under — the gate silently falls back to rhiza-task's default of 90%, and it returns to green when restored.

Final CI state: 49 pass, 0 fail. The two skipping entries are expected — mutation
is gated on a repository variable that is not set, and book / deploy only runs after
merge.